home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / dcom / modems-part1 / 4813 < prev    next >
Encoding:
Text File  |  1996-08-05  |  3.5 KB  |  68 lines

  1. Newsgroups: comp.dcom.modems
  2. Path: onramp.ca!geac!itcyyz!xrtll!bokonon!stephen
  3. From: stephen@bokonon.ussinc.com (Stephen M. Dunn)
  4. Subject: Re: To V42Bis or not to V42Bis??
  5. Organization: United System Solutions Inc.
  6. Date: Sat, 10 Feb 1996 00:38:28 GMT
  7. Message-ID: <DMJB44.1J6@bokonon.ussinc.com>
  8. References: <4etjse$a0g@azure.acsu.buffalo.edu> <1518.6606T1064T2337@crl.com>
  9.  
  10. In article <1518.6606T1064T2337@crl.com> joewald@crl.com (Joseph Waldvogel) writes:
  11. $Unlike MNP-5, V.42BIS is quite SMART!  You can always just leave it on, I'll
  12. $only commpress files that arn't already commpressed.  If there commpressed,
  13. $V.42bis is Smart enough to leave them as they are.
  14.  
  15.    Technically, a V.42bis compressor does _not_ have to be this smart.
  16. However, most (if not all) modem manufacturers did build this logic
  17. into their V.42bis compressors, so in real life, yes, V.42bis modems
  18. will realize when they're transmitting uncompressible data.  However,
  19. a V.42bis compressor can, if it wishes, continue sending the output of
  20. its compression routine, even if that output is larger than the
  21. input, and still comply with V.42bis, because V.42bis defines a way
  22. of signalling when the data is compressed or uncompressed but does not
  23. force the compressor to use this (the decompressor, however, must
  24. be able to handle it).
  25.  
  26.    V.42bis also doesn't specify how the compressor should determine
  27. when to send uncompressed data; that, too, is left up to the
  28. implementor.
  29.  
  30. $                                                    MNP-5  Data commpression
  31. $is pretty stuppied Your better off to leave THAT off!
  32.  
  33.    It depends on what you're doing.  If you're transferring data which
  34. is not compressible by MNP5, then yes, you should leave MNP5 disabled.
  35. If you're transferring text files, then MNP5 is a big win.
  36.  
  37.    This is becoming a less important point all the time, fortunately.
  38. Over the last several years, most modems sold with MNP5 have also had
  39. V.42bis, I'm sure; I don't recall the last time I saw a new MNP5 modem
  40. which did _not_ support V.42bis.  Yes, there are still some legacy
  41. modems out there which do MNP5 but not V.42bis, but I'd imagine that
  42. as a percentage of all modems in use, that number is relatively
  43. small and shrinking.
  44.  
  45. $                                  Leaving V.42bis OFF will NOT speed up
  46. $Downloading of Commpressed files,
  47.  
  48.    Actually, it should, by a factor of about 1/256 (or roughly 0.4%).
  49. Imagine you're a modem with V.42bis, and you're sending some data
  50. which you can't compress.  At some point, the data becomes compressible
  51. again.  You need a way of signalling to the modem at the other end
  52. that you're starting to compress the data again.  This is done by
  53. inserting a token into the data stream; for the sake of argument,
  54. let's say it's the ASCII code for the letter a.  If the letter a
  55. happens to appear in the uncompressible data stream, you need
  56. some way of indicating to the other side that it's just a letter
  57. a, and not a signal that you're compressing the data again.  Therefore,
  58. this character must be escaped.  On average, in uncompressible 8-bit
  59. data, the letter a should appear once out of every 256 characters,
  60. and so for every 256 characters of data, you will need to transmit
  61. an average of 257 characters (255 characters, plus the one letter
  62. a and one escape character).
  63. -- 
  64. stephen@bokonon.ussinc.com               ...!{xrtll,gts.org}!bokonon!stephen
  65. ----------------------------------------------------------------------------
  66. Stephen M. Dunn, CNE, ACE, Sr. Systems Analyst, United System Solutions Inc.
  67. 104 Carnforth Road, Toronto, ON, Canada M4A 2K7          (416) 750-7946 x251
  68.